Process DevSecOps

Intro

Le métier de DevSecOps combine développement, opérations et sécurité pour assurer la livraison rapide et sécurisée d’applications. Le DevSecOps intègre la sécurité dès les premières étapes du cycle de développement (shift-left), en automatisant les tests, l’analyse de vulnérabilités et le déploiement. Il collabore étroitement avec les développeurs, les ingénieurs systèmes et les équipes de sécurité pour mettre en place des pipelines CI/CD robustes et conformes. Il surveille les applications en production, réagit aux incidents, et améliore continuellement les pratiques de sécurité. Son objectif est de garantir des livraisons fiables, sûres, rapides et conformes aux normes réglementaires et aux exigences métier.

Les applications concernées par le DevSecOps sont :

• Coder : un système de déploiement d'environnements de Développements (IDE) déportés. Il permet de développer directement dans la plateforme.
• Gitea : une plateforme légère, auto-hébergée, de gestion de code source avec Git, offrant collaboration, wiki et dépôt de librairies.
• Gitlab : une plateforme DevOps complète permettant la gestion du code, l’intégration continue, le déploiement, la collaboration et le suivi projet.
• Sonarqube : un outil open source d’analyse continue de code, détectant bugs, vulnérabilités et mauvaises pratiques dans divers langages.
• Zot Registry : une registry OCI légère, sécurisée et extensible, conçu pour gérer des images de conteneurs et des artefacts.

Mise en place d'un environnement de développement

Une fois la procédure de création de zone joué, notamment pour la partie Gitlab, l'utilisateur doit se connecter une première fois à Gitlab pour que son utilisateur soir créé et demander à son administrateur des accès de lui donner les droits nécessaires.

L'utilisateur peut aussi se connecter à Coder afin de se créer un IDE. L'utilisation de Personal Access Token permet de communiquer avec gitlab avec les différents outils GIT.

Import de code source

Lorsqu'un projet est prêt à être livré, il faut l'exporter depuis son gitlab d'origine :

• Dans le panneau latéral gauche du projet, cliquez sur Settings
• Allez dans la section Advanced puis dans la sous-section Export project
• Cliquez sur le bouton Export project
• Après un certain temps (dépendant de la taille du projet), si vous rechargez la page un nouveau bouton Download export apparaitra.
• Cliquez dessus afin de récupérer une archive d'export

Il convient par la suite d'importer le projet :

• Placez vous dans l'arborescence gitlab à l'endroit où vous souhaitez importer votre projet
• Cliquez sur le bouton New project
• Sélectionnez le mode Import project
• Cliquez sur le bouton Gitlab export
• Configurez votre projet à importer :
  • Donnez un nom à votre projet
  • Cliquez sur le bouton Choose a file et choisissez l'archive d'export
• Validez et attendez la fin de l'import.

Développement, déploiement et tests dans le BaS

La plateforme est livrée avec un Groupe Toolbox contenant :

• Une toolbox par défaut qui contient des templates de CI/CD qui peuvent être ré-utilisés par les différentes chaines CI/CD de la plateforme
• Des exemples de code avec une chaine de CI/CD qui utilise les templates mentionnés ci-dessus dans un sous-groupe Samples.
  • Ces chaines contiennent par exemple des étapes de :
    • Compilation
    • Test
    • Qualimétrie SonarQube
    • Génération de l'image Docker de l'application
    • Déploiement en BaS de l'application basé sur l'archive helm du projet
    • Génération sur TAG Git d'une archive SAP compliant & dépôt dans un S3 auquel SAP à accès

remarque

Les projets d'exemples ne disposent pas de runner ou d'agent gitlab, si vous souhaitez tester ceux-ci, il vous faudra fork le projet dans un des groupes de votre zone.

Pour faire cela, une fois dans un projet, tout en haut à droite de l'UI, un bouton fork est disponible.

Utilisation des espaces de stockage

Les données utilisées par une application en développement peuvent être :

• des données d'EdS existants dans l'environnement de production
• des données d'EdS créés dans le BaS afin de tester l'application
  • alimentés par des données de test apportées par l'application
  • alimentés par une source externe
  • alimentés par un Data Ingénieur depuis le bac à sable

Plus d'informations dans :

• la section création des EdS.
• la section récupération des informations de l'EdS.

Livraison d'une application

La livraison d'une application s'effectue via la chaîne de CI qui copie l'archive dans un bucket S3 à l'intention d'un Administrateur Application ou un Intégrateur. Son déploiement se fera alors via SAp, pour plus d'informations consulter la section Déploiement d'une application.

Comme indiqué dans la section Développement et tests dans le BaS, des exemples de CI/CD montrent comment créer une archive SAp compliant directement depuis un projet existant dans le BaS.

L'archive ainsi généré est déposé dans un S3 auquel SAP a accès. Lors de l'import SAP, il est maintenant possible de choisir S3 comme source de l'import et d'y récupérer directement l'archive au lieu de passer par le poste utilisateur.

Ajout d’une librairie dans le dépot ARTEMIS.IA

Ce parcours permet d'enrichir le système avec de nouvelles librairies pour les développeurs, vous trouverez plus d'informations dans la section package importer.